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(54) Server-based electronic wallet system 

(57) Purchases from a wireless device are facilitat- 
ed by detecting, at a proxy (14), that a wireless device 
is attempting to access a form from a merchant server 
(18). The form is automatically filled at the proxy and 
delivered to the wireless device together with a hyperlink 
to a file stored on a wallet server (17). Upon receipt at 
the wallet server of an instruction from the wireless de- 
vice, information is delivered to the merchant server to 



complete a transaction. Also, a wireless device (10) is 
provided having a browser for sending, to an Internet 
connected gateway, a request to access a form from a 
merchant server (18). Upon receipt from a proxy, the 
wireless device receives, stores and presents to a user 
a representation of the form pre-f illed with data relating 
to the user, together with a hyperlink to a file and an 
indication that activation of the hyperlink will complete 
a transaction. 
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D scription 

Fi Id of the Inventi n 

[0001 ] This invention relates to wireless devices, such 
as WAP based cellular telephones and the like, and it 
relates to facilitating e-commerce services to automati- 
cally fill payment (and similar) forms for transactions 
made over the Internet using such devices. 

Background of the Invention 

[0002] Electronic Commerce (e-commerce) transac- 
tions over the Internet involve consumers browsing 
product listings on merchant pages and adding items 
that they wish to purchase into an electronic "shopping 
cart". When the consumer is ready to pay for the set of 
purchased items, he/she is presented with a "payment 
page", which is a form containing details of the consum- 
er. The details required may include: name and address 
of consumer, shipping address, postal address, credit 
card number, credit card expiry date etc. Often the 
number of such fields that need to be filled in range from 
ten to fifty, depending on the type of transaction and the 
items purchased. 

[0003] On a conventional PC environment, the pay- 
ment form displays in the Web browser and the consum- 
er tabs through each field and fills in the appropriate val- 
ue. Owing to the tedium involved in filling out such forms, 
a class of applications called "electronic wallet" has 
emerged. These applications store the user's details 
(such as addresses, credit card information etc.), in a 
single location. When the consumer encounters a pay- 
ment form page, he/she simply "drags-and-drops" the 
icon of the wallet over the browser page. The wallet au- 
tomatically fills in the form with all the relevant and ap- 
propriate information. The consumer then simply sub- 
mits the form to complete the transaction. 
[0004] Electronic wallets are known in PC environ- 
ments, where the consumer "drags-and-drops" a wallet 
client icon over a payment form that he/she has received 
from a merchant site. The wallet client uses technolo- 
gies such as OLE (object linking and embedding), DDE 
(dynamic data exchange) etc, to elicit information about 
the page and sends a request to the wallet server. The 
response from the wallet server is carefully inserted into 
the form fields, again using OLE or Active-X controls or 
the like. This process and technology cannot be used in 
cellular phones since, among other limitations, there is 
no simple and convenient means of performing a "drag- 
and-drop" or equivalent operation. 
[0005] Additionally, in the cellular phone environment 
the process of detection of the payment page is a prob- 
lem. 

[0006] There is an increasing demand for wireless In- 
ternet services to be made available on handheld mobile 
telephones and an electronic wallet would be a great 
advantage in the cellular, WAP based, Internet e-com- 



merce environment. A cellular phone user has a very 
limited screen display and a cumbersome keypad to en- 
ter text. It would be very difficult and time consuming for 
users to manually enter payment details. The PC-style 

5 wallet is not feasible because the current state-of-the- 
art in cellular phones does not permit dynamic download 
and installation of third party applications on the cellular 
phone and advanced "drag-and-drop" features. 
[0007] Hence there is an urgent need for a method 

10 that enables the consumer to request a remote server 
to fill up a form on his/her behalf. The invention disclosed 
herein solves this problem. 

Summary of the Invention 

15 

[0008] According to a first aspect of the present inven- 
tion, a method of facilitating purchases from a wireless 
device is provided comprising: detecting, at a proxy, that 
a wireless device is attempting to access a form from a 
merchant server, where the form requires information to 
be entered; automatically filling the form at the proxy; 
delivering the f illed-in form to the wireless device togeth- 
er with a hyperlink to a file stored on a wallet server; and 
upon receipt at said wallet server of an instruction from 
the wireless device, delivering to the merchant server 
information to complete a transaction. 
[0009] The step of detecting preferably comprises re- 
ceiving a request from the wireless device, parsing the 
request and comparing it with a pre- determined list of 
merchant form identifiers. The pre-determined list pref- 
erably includes associated mappings between fields of 
merchant forms and fields of user personal details. 
[0010] The step of receiving preferably comprises re- 
ceiving a wireless protocol request at a wireless gate- 
way and converting it to a HTTP request. 
[0011] In accordance with a further aspect of the in- 
vention, a proxy is provided for facilitating purchases 
from a wireless device. The proxy comprises a memory 
to store a list of predetermined merchant form URLs, a 
parser and filter for identifying by comparison with said 
list an incoming attempt from a wireless device to ac- 
cess a form from a merchant server; a form-filling soft- 
ware program for filling the form at the proxy; a socket 
to a wireless gateway for delivering the filled-in form to 
the wireless device together with a hyperlink to a file 
stored on a wallet server and for receiving an instruction 
from the wireless device; and a socket to a wallet server 
for delivering the instruction to the wallet server to com- 
plete a transaction. 

[0012] The invention further provides a data storage 
medium having stored thereon wallet proxy computer 
instructions that, when loaded onto a gateway server, 
cause the gateway server to operate as a proxy that: 
receives, parses and filters requests from wireless de- 
vices; identifies an attempt to access a form from a mer- 
chant server, where the form requires information to be 
entered; automatically fills the form with user data; and 
delivers the filled-form to a wireless device through the 
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gateway, together with a hyperlink to a file stored on a 
wallet server. 

[0013] In accordance with a further aspect of the in- 
vention, a method of operation of a wireless device by 
a user is provided. The method comprises: sending, to 
an Internet connected gateway, a request to access a 
form from a merchant server, where the form requires 
information to be entered; receiving from the gateway a 
representation of the form pre-filled by wallet software 
associated with the gateway with data relating to the us- 
er, together with a hyperlink to a file stored on a wallet 
server further associated with the wallet software; and 
selectively activating the hyperlink to the file to activate 
a transaction with the merchant server. Also, a wireless 
device is provided having a browser for sending, to an 
Internet connected gateway, a request to access a form 
from a merchant server, where the form requires infor- 
mation to be entered; characterized in that, upon receipt 
from a proxy, the wireless device receives, stores and 
presents to a user a representation of the form pre-filled 
with data relating to the user, together with a hyperlink 
to a file and an indication that activation of the hyperlink 
will complete a transaction. 

[0014] Thus the present system, method and soft- 
ware facilitates filling up of forms remotely and the send- 
ing of the f illed-in form back to the wireless (or other re- 
mote) device of the consumer for final submission. 

Glossary of Terms 

[0015] 

e-wallet electronic wallet implemented as wallet cli- 
ent software 

HREF HTML term to specify links in HTML web 
pages 

HTTP HyperText Transfer Protocol 
PC Personal Computer 

URL Universal Resource Locator 
WAP Wireless Application Protocol 
WML WAP Markup Language 
WSP wireless session protocol 

Brief Description of the Drawings 
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[0016] 



FIG. 1 is an overall block diagram of a system in 

accordance with the invention. 

FIG. 2 is a breakdown of the elements that make up 

the wallet proxy 14 of FIG. 1. 

FIGs. 3, 4, 5 and 6 illustrate steps in the operation 

of the wallet proxy of FIG. -2; and 

FIG. 7 is a message flow diagram for purposes of 

describing the exchanges of messages between 

the various elements of FIG. 1 
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55 



Detailed D scription of the Drawings 

[0017] The major components of the system are 
shown in FIG. 1 and comprise: a cellular telephone 
("mobile phone") 10 or other wireless device (personal 
digital assistant, etc.) capable of communicating via the 
Wireless Application Protocol (WAP); a WAP gateway 
12; a wallet proxy 14, which is software that can run on 
a server connected to the WAP gateway 12 or on the 
same server as the WAP gateway 1 2; a wallet client 1 6 , 
which is software that preferably runs on another server; 
a wallet server 17; and a merchant site 18 (i.e. a web 
site running on a merchant's server). The cellular tele- 
phone 10 has a memory and microprocessor on which 
a browser 11 is stored and run, and a display 13 which 
is preferably touch-sensitive so that buttons and hot 
links can be activated (but the cellular telephone may 
be implemented with alternative input and output devic- 
es). 

[0018] In greater detail, and with reference to FIG. 2, 
the wallet proxy 1 4 comprises a client socket 21 coupled 
to the WAP gateway 12 and a relay 22 coupled to the 
client socket 21 . The relay 22 is coupled to a wallet sock- 
et 24. The wallet socket is coupled to wallet interface 
software 34, which is in turn coupled to the wallet client 
(a form of proxy). The relay 22 is also coupled to a server 
socket 26 (in turn coupled to the merchant site 1 8). The 
relay 22 is capable of relaying HTTP messages 30 com- 
prising a HTTP header 31 and a message body 32. The 
relay 22 includes a filter 28 and a parser 29. The filter 
28 has an associated memory 25 that stores a list of 
merchant pay page URLs which is updated from time- 
to-time by a remote link 27 (which can be an Internet 
connection, for example, could take other forms). 
[0019] In operation, a user using the browser 11 in- 
stalled in the telephone 10 selects a URL. This URL is 
sent to the WAP gateway 1 2. The WAP gateway 1 2 con- 
verts WAP session protocol messages from the cellular 
telephone 10 to HTTP. The WAP gateway 12 is config- 
ured to forward all HTTP requests to the wallet proxy 
14. The wallet proxy 14 compares the URL with a list of 
merchant pay page URLs that it serves. This list is 
stored locally at the wallet proxy 14 and updated from 
time-to-time by a remote look-up operation. If the URL 
Is not recognized as a merchant pay page that is served 
by the wallet proxy software 14, the wallet proxy soft- 
ware 1 4 plays no further part and the WAP gateway per- 
forms its normal task connecting directly to the Internet 
(not shown). 

[0020] The wallet proxy 1 4 acts as a normal proxy for 
general HTTP requests, but the wallet proxy maintains 
a table in memory 25 of "prof iled" WML pages belonging 
to one or more merchants. Each profiled WML page is 
a WML form page with a number of field definitions (e. 
g. name, address, credit card number billing address). 
Differentmerchants request such details in different for- 
mats and different sequences. For example merchant A 
may request credit card details before shipping address 
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whereas merchant B may request shipping address be- 
fore credit card. Merchant C may additionally demand 
age related' information. The wallet proxy 14 profiles 
WML pages by storing, for each merchant page support- 
ed, a mapping of field definitions to specific values 
based on user date (including name, address, credit 
card details and shipping address). A "profiled" WML 
page in this context is a WML form page whose field 
definitions have been analyzed and mapped in th is man- 
ner. 

[0021 ] Filter 28 filters requests to "profiled" WML pag- 
es. When such request is identified (FIG. 3.), the wallet 
proxy 1 4 adds an extra WML card with a special anchor 
(HR EF) to allow the consumerto use a server side wallet 
to fill up the pay page. This WML card is sent to the tel- 
ephone 1 0 via the WAP gateway 12. The WML card has 
a button or URL that can be activated by the user. 
[0022] When the consumer receives the WML card 
and selects this option (i.e activates this button or URL), 
the wallet proxy 1 4 intelligently directs the request to the 
wallet client 16 (FIG. 4) together with all the necessary 
information to authenticate the user to the wallet client 
1 6. The wallet client 1 6 processes this information and 
places a request to the wallet server 17 to furnish ap- 
propriate values for the fields in the merchant's pay 
page. 

[0023] The wallet server 1 7 extracts the user's credit 
card information and the merchant's pay page profile 
and tries to match all the fields with the appropriate user 
information. If sucessful, this is returned to the wallet 
interface software 34, which performs the task (FIG. 5) 
of filling up the WML form (i.e. auto-filling the merchant's 
pay page with user data from the wallet client 16) and 
returning it to the user's mobile phone 1 0 (or WAP ena- 
bled mobile device). At this point the user sees the orig- 
inal pay page of the merchant, but with all fields filled in. 
The user then simply navigates through the card until 
he/she gets to the link to commit the order ("Make Pay- 
ment" page), and then follows that link in order to com- 
plete the transaction (FIG. 6). 

[0024] The set of interactions during a payment ses- 
sion are described in greater detail now with reference 
to FIG. 7. 

[0025] Step A - the browser 11 in the WAP mobile 1 0 
initiates a WSP request for a merchant's "payment form 
page", which is translated into an HTTP request either 
at or before the WAP gateway 1 2, and forwarded to the 
wallet proxy 14. (The wallet proxy 14, and wallet client 
16 only understand HTTP). 

[0026] Step B - the wallet proxy 14 checks if the re- 
quest is for a profiled merchant's page. If it is, an "alert" 
field is set up in order to intercept the response. The 
wallet proxy 14 then forwards the request to the mer- 
chant's site 18. 

[0027] Step C - the merchant site 18 responds with 
the "payment form page". 

[0028] Steps D and D' - the wallet proxy 14 caches 
the response page in a cache 40. (This is used when 



6 

the wallet client 16 later needs the page). The wallet 
proxy 14 also adds a special WML card to enable the 
user to choose if he/she wants to use the wallet client 
to make the payment or fill the form themselves. The 
5 "pay by wallet" URL contains information about the 
cached file. 

[0029] Step E - the user selects to use the e-wallet. 
The mobile device forwards the request to the WAP 
gateway 1 2 and then the wallet proxy 14. 
10 [0030] Step F - the wallet proxy 14 redirects the re- 
quest to the wallet client 16. 

[0031] Step G - the wallet client 1 6 extracts the filena- 
me of the cached WML page and requests the cache 
for the WML page. 

15 [0032] Step H - the cache 40 returns the original file 
containing the merchant's pay page. 
[0033] Step I - the wallet client 16 forwards user and 
merchant information to the wallet server 1 7. 
[0034] Step J - the wallet server 17 returns with the 

20 appropriate name value pairs for making the payment. 
[0035] Step K - the wallet client 16 uses this to fill in 
"default" values into the WML page (that it retrieved from 
the cache) and pushes it back to the client. 
[0036] Step L - the wallet proxy 14 returns the page 

25 to the WAP device. The new "default" values for every 
field are displayed on display 13 within the browser 11 . 
[0037] Step M - the user checks if the values are cor- 
rect and proceeds to commit the transaction by activat- 
ing a button on the touch sensitive screen 13. 

30 [0038] Step N - the wallet proxy 14 forwards the GET 
or POST to the merchant site 1 8. 
[0039] Step O - the merchant site 18 responds with 
the "payment complete" page. 

[0040] Step P - the "payment complete" page is re- 
35 turned to the WAP device 1 0 (mobile phone) and is pref- 
erably displayed. 

[0041] In this manner the filter 28 of the wallet proxy 
1 4 checks if a given page returned from an external Web 
site is a payment page of a known merchant. When it 

40 recognises such a page, it stores the page in a special 
location locally, and adds valid content into the page to 
prompt the consumer to choose if he/she desires to 
make the payment using the electronic wallet. The wal- 
let proxy 1 4 then sends it to the consumer on the usual 

45 channel. Part of this added content is a special hyperlink 
URL that encodes the address of the wallet client 1 6 and 
the cache fi le ID of the original file returned from the mer- 
chant. If he/she chooses to pay using the electronic wal- 
let (by following the specially inserted hyperlink), the 

50 consumer is prompted to enter a login name and pass- 
word. This is done in order to authenticate the user to 
the wallet server 17. When the consumer chooses to 
send this information, a connection to the wallet client 
16 is established and an appropriate request is sent. 

55 The wallet client 16 authenticates the consumer and 
commences the form filling process. It first obtains the 
original page from the wallet proxy 14 by requesting for 
the file with the file id given in the consumer's request. 
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It then establishes a connection with the wallet server 
17 that stores information about the consumer and the 
profiled merchant's pay page fields. The wallet client 1 6 
• uses the information returned by the wallet server 1 7 in 
order to insert "default value" attributes to the field tags 
of the form page. On completion of this task : it returns 
the page to the consumer. The consumer then proceeds 
to check if all the fields contain the correct values : and 
if satisfied chooses the hyperlink to complete the trans- 
action. The request is forwarded to the merchant site for 
completion of the transaction. 

[0042] In accordance with this technique, cookie in- 
formation can be preserved and the browser and the 
merchant site are kept oblivious of the existence of the 
wallet client 1 6 and the wallet server 1 7. The key to this 
lies in the special hyperlink URL that is added by the 
wallet proxy's filter that points to the wallet client 16. In 
reality the URL still points to the merchant site and to 
the current dreclory (of the merchant's server) from 
which the page was retrieved. However, a special "alert 
trigger" is appended to this in the "file" and "query string" 
part of the URL. This trigger text is recognised by the 
wallet proxy 1^ and all requests with such URLs are giv- 
en a special treatment. An example is shown below to 
illustrate this. 

Example 1. 

[0043] If the payment page from the merchant site had 
the following URL (example only): 

http://merchant.com:80/wml/pay/payStep.asp? 
a=1;b=3;step=5 

then the wallet proxy 1 4 will create the special URL 
for initiating wallet payment as (example only): 
http://merchant.com: 80/wm l/pay/ @ @eWal let Re- 
direct @ @?http://e Wall et.com :80 70/username=$ 
(username):password=$(password);cache/file- 

num212345 

[0044] When the browser is requested to follow such 
a hyperlink, it believes that it is contacting the merchant 
site. The request arrives at the wallet proxy 14 : which 
detects that it is a special request and instead of con- 
tacting the merchant site (http://merchant.com:80) , the 
wallet proxy parses the URL string and extracts the real 
URL, which is: 

http://eWallet.com:8070/username=$(username); 
password=$(password);cache/fil e-num212345 
and it sends a request to this address. 

[0045] The completed form is sent back to the con- 
sumer as a result of this request and contains all the 
hyperlinks intact as sent by the merchant. The only" 
change is the inclusion of "default values" for all the input 
fields. These are set to the appropriate values for the 
particular consumer, based on information extracted 
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from the wallet server 17. On receiving the completed 
page the consumer can satisfy himself/herself that the 
values are valid and then submit the form to the mer- 
chant. The consumer's browser would send all the rel- 
evant cookies to the merchant because as far as the 
browser was concerned, thefilled-in page was returned 
from the merchant site. In this process the merchant site 
was not informed of the additional processing that was 
performed. The consumer's browser was also kept ob- 
livious of the existence of the wallet client 1 6 and wallet 
server 17. 

[0046] Without this invention, consumers who wish to 
purchase items over the Internet using a cellular phone 
would have to manually fill-in payment details using the 
phone's restricted keypad and limited display. Such a 
handicap would severely restrict the use of cellular 
phones for e-commerce purposes - and thus cause the 
Internet service provider to lose a significant portion of 
the market. The invention described and claimed pro- 
vides a technique for intercepting form pages, filling the 
pages with relevant information, and returning the filled 
in forms to the user - ready for submission to the issuing 
merchant. These tasks are performed without disturbing 
any HTTP cookies sent by the merchant and without in- 
volving the merchant's Website in the form filling proc- 
ess. 

[0047] The above description has been given by way 
of example only. Numerous and varied modifications of 
detail can be made within the scope of the invention. 
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Claims 

1. A method of facilitating purchases from a wireless 
device comprising: 

detecting, at a proxy, that a wireless device is 
attempting to access a form from a merchant 
server, where the form requires information to 
be entered; 

automatically filling the form at the proxy; 
delivering the filled-form to the wireless device 
together with a hyperlink to a file stored on a 
wallet server; and 

upon receipt at said wallet server of an instruc- 
tion from the wireless device, delivering to the 
merchant server information to complete a 
transaction. 



50 2. The method of claim 1 , wherein the step of detecting 
comprises receiving a request from the wireless de- 
vice, parsing the request and comparing it with a 
pre-determined list of merchant form identifiers. 

55 3. The method of claim 2, wherein the pre-determined 
list includes associated mappings between fields of 
merchant forms and fields of user personal details. 
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4. The method of claim 2, wherein the step of receiving 
comprises receiving a wireless protocol request at 
a wireless gateway and converting it to a HTTP re- 
quest. 

5. The method of claim 1 , wherein, following the step 
of detecting, retrieving the form from the merchant 
server and caching it in a cache at the wallet proxy. 

6. The method of claim 5 further comprising retrieving 
the form from the cache upon receipt of an invoke 
instruction to invoke the wallet proxy. 

7. The method of claim 6, wherein the step of filling 
the form proceeds from the step of retrieving the 
form from the cache. 

8. A proxy for facilitating purchases from a wireless 
device comprising: 

a memory to store a list of predetermined mer- 
chant form URL's, 

a parser and filter for identifying by comparison 
with said list an incoming attempt from a wire- 
less device to access a form from a merchant 
server, where the form requires information to 
be entered; 

a form-filling software program for filling the 
form at the proxy; and 

a socket to a wireless gateway for delivering the 
filled-in form to the wireless device together 
with a hyperlink to a file stored on a wallet serv- 
er and for receiving an instruction from the wire- 
less device; and 

a socket to a wallet server for delivering the in- 
struction to the wallet server to complete a 
transaction. 
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er, where the form requires information to be 
entered; 

receiving from the gateway a representation of 
the form pre-filled by wallet software associat- 
ed with the gateway with data relating to the us- 
er, together with a hyperlink to a file stored on 
a wallet server further associated with the wal- 
let software; and 

selectively activating the hyperlink to the file to 
activate a transaction with the merchant server. 

11 . A wireless device having a browser for sending, to 
an Internet connected gateway : a request to access 
a form from a merchant server, where the form re- 
quires information to be entered; characterized in 
that, upon receipt from a proxy, the wireless device 
receives, stores and presents to a user a represen- 
tation of the form pre-filled with data relating to the 
user, together with a hyperlink to a file and an indi- 
cation that activation of the hyperlink will complete 
a transaction. 



25 



30 



35 



A data storage medium having stored thereon wal- 
let proxy computer instructions that, when loaded 40 
onto a gateway server, cause the gateway server 
to operate as a proxy that: 

receives, parses and filters requests from wire- 
less devices; 45 
identifies an attempt to access a form from a 
merchant server, where the form requires infor- 
mation to be entered; 

automatically fills the form with user data; and 
delivers the filled-form to a wireless device 50 
through the gateway, together with a hyperlink 
to a file stored on a wallet server. 



1 0. A method of operation of a wireless device by a us- 
er, the method comprising: 

sending, to an Internet connected gateway, a 
request to access a form from a merchant serv- 
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(54) Server-based electronic wallet system 

(57) Purchases from a wireless device are facilitat- 
ed by detecting, at a proxy (14), that a wireless device 
is attempting to access a form from a merchant server 
(18). The form is automatically filled at the proxy and 
delivered to the wireless device together with a hyperlink 
to a file stored on a wallet server (17). Upon receipt at 
the wallet server of an instruction from the wireless de- 
vice, information is delivered to the merchant server to 



complete a transaction. Also, a wireless device (10) is 
provided having a browser for sending, to an Internet 
connected gateway, a request to access a form from a 
merchant server (18). Upon receipt from a proxy, the 
wireless device receives, stores and presents to a user 
a representation of the form pre-filled with data relating 
to the user, together with a hyperlink to a file and an 
indication that activation of the hyperlink will complete 
a transaction. 
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